В статье предлагается оригинальный подход к оценке достоинств и недостатков существующих инструментов организационного проектирования и проектирования бизнес-процессов (БП), основанный на принципе «подавления» многообразия в работе организационного «модельера». Основная идея заключается в анализе соответствия существующих инструментов требованию снижения «проектного хаоса», обусловленного контекстной, методической, выразительной свободой, предоставляемой модельеру проектной процедурой. Возможный путь борьбы с «проектным хаосом» автором видится в повышении организации интеллекта модельера посредством процедуры, сокращающей многообразие представлений организации (выбора языка (методологии) описания БП, инструмента моделирования БП, методологии управления и общей модели БП). Общая склонность к разработке программных продуктов, удовлетворяющих «пестрым» потребностям пользователей, и, как следствие, предоставление модельерам возможности выражения различных точек зрения, оборачиваются несоответствием свойств инструментов задаче подавления «проектного хаоса».

О плюрализме и дискуссиях

Несколько событий последнего полугодия ( диспут, развернувшийся в журнале «ДИС» после публикации статьи П. Сахарова, обсуждение с собственным руководством и сотрудниками инструментов организационного реинжиниринга в процессе их приобретения, участия в диспутах в известных www-форумах, посвященных той же теме, и консультации поставщиков программных продуктов ) заставили меня по-новому посмотреть на задачу инструментальной поддержки организационного проектирования.

Главный вывод состоял в том, что сравнение существующих CASE-инструментов по развитости функциональных признаков - крайне непродуктивный процесс. Очевидно, что истину из изложения отдельных мнений трудно извлечь. В первую очередь, это связано с тем, что ситуация, когда предприятие владеет парком разнообразных инструментов для проектирования организационных процессов и квалифицированными специалистами с высокой степенью мастерства обращения с этими инструментами, вряд ли может быть типовой моделью [1, 2]. Вероятно, эта модель может быть воплощена в жизнь с большими усилиями и только в небольшом числе специализированных организаций. Часто слабость мотивировок в защиту конкретных CASE-инструментов, приводимых специалистами в области реинжиниринга БП (РБП), объективна и обусловлена трудностью или нецелесообразностью овладения в совершенстве более, чем одним CASE-инструментом. По этой же причине мнение такого специалиста – лишь отражение степени совместимости его мировоззрения, сформированного опытом ни одного года работы с любимым инструментом, с сервисом, предлагаемым другими инструментами. Последнее полностью справедливо и в отношении поставщиков программных продуктов. Следовательно, любой сравнительный анализ инструментов проектирования и управления проектами должен изначально вызывать здоровое сомнение, если он, конечно, не является плодом усилий большого коллектива авторитетных экспертов.

Поэтому, плюрализм мнений хорош только тем, что каждым субъективным мнением можно пренебречь. Ведь это всего лишь одно из личных мнений…! А вот мнением поставщиков программных продуктов пренебречь невозможно. Следовательно, публичный плюрализм пользователей CASE-инструментов будет объективно поддерживаться как необходимое условие защиты интересов поставщиков (например, Interface, Весть МетаТехнология, ВИП Анатекс и др.). Из сказанного следует, что важно определиться не с традиционно узкими технологическими аргументами «за» и «против» предлагаемых на рынке инструментов реинжиниринга, а с оценками этих технологий с точки зрения их соответствия главной цели РБП – управлению изменениями.

О развитии инструментов РБП

Задача управления изменениями в организации осложняется «проектным хаосом», обусловленным множеством причин. Одна из них - многообразие возможностей и их сочетаний, вносимых языком (нотациями) описания БП и возможностями инструмента проектирования БП. Условия усиления «проектного хаоса» объективно создаются разработчиками и поставщиками инструментов, которые идут на встречу интересам разнородных пользователей, а не «узких» заказчиков продуктов, изготавливаемых с помощью этих инструментов. Одним из таких «узких» заказчиков является собственно организация, приспосабливающаяся к агрессивной среде и нуждающаяся в целенаправленных и упреждающих внутренних изменениях.

Управлять можно только тем объектом, модель которого существует в системе управления этим объектом. Это необходимое условие управляемости. Поэтому, основной целью проектирования организации является построение ее модели или в соответствии с современной концепцией управления изменениями – процессной модели организации.

Здесь мы сталкиваемся с традиционной проблемой сложности, подробно исследованной Стэффордом Биром в 70-х [3]. Объект анализа, на котором сосредотачивает свое внимание модельер, всегда демонстрирует растущее многообразие свойств по мере его изучения. Модельер не всеведущ в понимании объекта и в определении параметров «фильтрации», обрушивающейся на него информации в процессе разработки модели. При этом инструмент моделирования выступает не только как средство концептуального видения, но и как один из настраиваемых «фильтров» (наряду со зрением, слухом, механизмом логического вывода). Они подавляют многообразие до уровня восприимчивости модельером (обеспечивают гомеостаз модельера^[1]). Бир отмечал, что снижение многообразия не только положительно, но и часто приводит к застою гомеостаза и разрушению кибернетической системы. В нашем случае «жизненный цикл» модельера как правило значительно превышает жизненный цикл проекта, а снижение многообразия является необходимым условием формирования навыков моделирования. Часто разработчики инструментов, осознавая возможную узость инструмента и испытывая «испуг по Эшби» [3, стр. 377] , пренебрегают объективностью этой узости и снабжают инструмент избыточными свойствами. В результате, с ростом вариативности настройки «фильтра» (например, возможность выбора одной из нескольких равноценных нотаций) повышается «шум моделирования». Поэтому, инструменты могут работать как «фильтры», и как «усилители» шумового разнообразия. В данном контексте видятся два основных направления развития инструментов РБП.

Одно выражается в создании условий, снижающих степень свободы модельера. Это - определение жестких стандартов оформления умозаключений, обеспечивающих приемлемое взаимопонимание разработчиков и пользователей инструментов, поддерживающих весь проектный цикл, но не позволяющих «творить» так, как нам хочется. Классическим примером такого подхода является продукт Bpwin, поддерживающий стандарт IDEF0. Другое – охватывает лишь отдельные фрагменты проектного цикла и направлено на представление сервиса для выражения «творческих» взглядов на проектирование организационных процессов. Например, методология ARIS, предлагает рассматривать организацию с позиции 12 аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания БП предлагается использовать 85 типов моделей, каждая из которых принадлежит тому или иному аспекту. Другими словами, два подхода различаются количеством стандартных отношений, которые представляет программная среда для описания БП.

Условно известные стандарты проектирования БП обладают промежуточными свойствами в рамках описанных выше двух подходов. Назовем их, соответственно, «узкий, но глубокий» (т.е. способствует большой глубине проработки проектных решений, но обладает небольшим спектром репрезентативных возможностей) и «широкий, но мелкий» (т.е. предлагает широкий спектр стандартных объектов для описания БП, но не позволяет осуществлять полный цикл проектных работ). Например, стандарт IDEF0 «заставляет» нас представлять функциональную (или процессную) модель в виде иерархической структуры. Совместно со стандартами IDEF2,3 обеспечивая достаточную глубину проектной проработки, он «загоняет» проектировщика в рамки листового формата А4. Очевидно, не всем это нравится. Очевидно и другое – рефлексия пользователя инструмента, решающего частную задачу, должна подчиняться обоснованному выбору разработчиков стандарта, решающих системную задачу.

Разработчики инструментария по-разному пытаются угодить потребностям рынка. Так, попытки расширить возможности инструмента и придать ему свойства, обеспечивающие получение программного кода для поддержки БП, сводятся, с одной стороны, к ограничению множества отношений и объектов, которые можно описывать с использованием инструмента, и придание стандартным процессам более выразительной формы. Например, STORM2000, использующий нотацию UML при описании процессов высокого уровня с целью автоматической генерации информационной системы. Плата за такой сервис - предопределённая системная архитектура программного кода. С другой – к расширению множества отношений и объектов, но и к разделению труда, когда создаваемый инструмент не обеспечивает всей глубины проектного процесса и снабжается необходимыми интерфейсами для использования продуктов других популярных разработчиков. Так ARIS, неспособный генерировать код информационной системы, приобретает полнофункциональные свойства только после закупки соответствующих интерфейсов (например, в части формирования логической структуры баз данных и кодов приложений рекомендуется докупать интерфейс с ERwin).

Другими словами, заменой одних ограничений другими реализуется попытка снять возможные противоречия и расширить область применения инструмента. Насколько удачными будут эти попытки, естественно, покажет будущее. Однако, уже сейчас следует говорить о сомнительной целесообразности предложения «широких, но мелких» стандартов организационного проектирования. Все-таки основной целью инструмента РБП должно быть ускорение принятия решений об организационных изменениях, а не внесение препятствующего этому разнообразия, о чем уже говорилось выше. По различным данным от 30% до 80% реализаций РБП заканчиваются неудачей. Основная причина – инерционность РБП неадекватна скорости внешних изменений. Оперативность же достигается снижением количества вариантов в выборе или снижением многообразия. Отсюда – необходимость соответствия инструмента доктрине управления, культивируемой в организации. Например, может идти речь об отстаиваемом автором варианте концепции контроллинга, базирующейся на системе регулирования с обратной связью по отклонениям от программы развития предприятия. Этот подход к автоматизации управления предприятиями заставляет посмотреть под иным углом на свойства предлагаемых продуктов организационного проектирования.

Исследование операций и бизнес-процессы

Взрывной интерес к РБП в конце ХХ века вызван ожидаемым снижением производственных издержек при его реализации. Это цель так или иначе отразилась в противоречивых способах определения понятия «БП» [4]. Это обстоятельство, позволяет модельеру даже при наличии жесткого инструментального стандарта иметь многообразие представлений о модели БП. Подавление этого вида многообразия как условие повышение оперативности РБП может быть обеспечено дополнительным ограничением – стандартной моделью БП. Например, концепция контроллинга требует не только определенности, но и более глубокой разработки и стандартизации этой базовой категории с целью ее увязки с понятиями «целеполагание» и «пространство состояний» предприятия.

Независимо от того, является ли управление организациями наукой или искусством, оно может быть представлено в виде совокупности тех или иных приемов достижения целей организации. Однако, такие приемы однозначно воспринимаемым образом можно описать, лишь опираясь на научный подход. Например, в Исследованиях операций приемы управления отождествляются с понятием «операция». Операция определяется как "система объединенных общим замыслом действий, осуществляемых с ресурсом по известным правилам" [5, 6]. При этом, понятие ресурс имеет самое широкое толкование, а сам ресурс является неоднородным (это – информация, время, деньги, материалы, оборудования, интеллектуальная собственность, географические и пространственные границы операции, психическая энергия, знания, навыки, умения и т.д.).

Следовательно, предприятие, и как система, и как инструмент достижения неких целей – это множество операций, темп, последовательность и качество осуществления которых зависит от замысла владельца предприятий и действий исполнителей этого замысла. Именно здесь мы связываем мостиком две ипостаси бизнеса: операции как операционные возможности бизнеса, и процессы принятия решений как реализация этих процессов этих возможностей. Другими словами, важнейшей составляющей акта принятия решений является задание правил (режима, сценария) исполнения операции с учетом ее технологических особенностей и внешних факторов (информация о свойствах операций элементов внешней среды: нормативные акты внешних регулирующих органов, действия конкурентов, потребительский спрос и т.д.). Примерами таких действий, содержащих количественные и логические ограничения для исполнения тех или иных операций (свойства операций), являются приказания, распоряжения, положения, инструкции и т.д.

Исходя из сказанного, в дальнейшем изложении будем опираться на следующее определение БП, фиксирующее свойства последнего как операции в системе операций предприятия.

Здесь автор исходит из того предположения, что отношения субъектов предприятия всегда базируются на актах обмена продуктами труда, которые по Марксу в силу самого обмена становятся услугой (продуктом). Последовательно двигаясь в русле процессной методологии, все субъекты деятельности внутри предприятия могут быть представлены в виде БП.

Приведенное определение свидетельствует о том, что БП с учетом свойств понятия «операция» всегда может быть описан математической моделью – целевым функционалом и множеством ограничений. А это является важнейшим условием для постановки задачи глобальной оптимизации управления ресурсами.

Мы видим что, базовыми категориями в определении БП являются понятия «действие», «услуга (товар)» и «ресурс». Первое из них – это одно из простейших отношений между оперирующей стороной и предметом, которое является интуитивно ясным и, как правило, однозначно интерпретируемым. Под ресурсом обычно понимают реальный объект, существование которого предполагается, и стоимость или ценность которого не возрастает в процессе совершения операций над ним. Снижение ценности ресурса обусловлено, например, износом оборудования, усталостью или старением персонала, а информационный ресурс может не потерять своей ценности в процессе использования. Напротив, стоимость услуги (товара) в процессе ее производства и поставки возрастает. Т.е. ресурс является источником возникновения услуги (товара). В этом состоит основное отличие ресурса от услуги (товара) на интервале времени исполнения операции. Однако, и здесь не все так однозначно и исходные понятия требуют дополнительной контекстной конкретизации.

В первую очередь, здесь имеется в виду то, что конкретная операция может рассматриваться в другой бизнес-модели как ресурс (например, в нотации IDEF0 как механизм). С другой стороны, как правило, услуга (товар) является ресурсом для операции - потребителя этой услуги (товара). Поэтому, при использовании этих понятий следует четко определять, к каким операциям они имеют отношение, а также осознавать, что это определение справедливо только на интервале времени исполнения рассматриваемой операции.

Относительность понятия «услуга» проявляется не только в его контекстной связи с конкретной операцией, но и в его частом несоответствии обыденному представлению об услуге, а также в его синонимии с понятием «воздействие». Например, как классифицировать действия отца, применившего розги к своему непослушному чаду? С точки зрения отца – это, возможно, и услуга…, а с точки зрения современного юриста – незаконное воздействие J . Аналогично обстоит дело с услугой «доведение руководителем рабочего задания до исполнителя». С целью избежать такой ситуации целесообразно полагать, что понятия «предоставление услуги (поставка товара)» и «оказание воздействия» независимо от особенностей восприятия того или иного субъекта эквивалентны по своей сути (!).

Описанная выше модель БП с относительной степенью точности поддерживается технически многими инструментами. Однако, по мнению автора, одновременное обладание данным свойством и свойством подавления многообразия на уровне языка описания БП свойственно в наибольшей степени инструментам, поддерживающим методологию SADT.

Процессная модель предприятия как критерий адекватности корпоративных систем управления

Известно, что мировоззрение человека, как правило, формируется методом, который он использует для решения проблем. Если он смотрит на организацию как на функциональную иерархию, то на обобщенной модели БП он будет отображать административную структуру. Если он – узкий финансист, то разработка модели БП начнется с описания финансовых потоков. Приверженец кибернетического подхода, которым является автор, увидит организацию в виде трех крупных блоков: «анализатор – моделятор - регулятор». В контексте задачи подавления многообразия, выражающегося в «проектном хаосе», сказанное, очевидно, не является гимном плюрализму. Модель БП должна быть адекватна методу. Приведение модели БП в соответствие с методом управления – эффективный путь снижения многообразия.

Например, модель БП может соответствовать классической универсальной модели контура саморегулирования и, следовательно, декомпозироваться на три базовые операции: (1) анализ результата поставки услуги (товара) или воздействия, (2) моделирование потребителя и разработка услуги (товара) или воздействия, (3) разработка, производство и поставка услуги (товара) или воздействие [7]. Это основополагающее свойство БП является необходимым для решения БП задач самоорганизации и управления другими БП. IDEF0-модель такого процесса изображена на Рис. 1.

Рис. 1. Универсальная процессная модель предприятия

Очевидно, в простейших БП базовые операции (1) и\или (2) могут не учитываться при построении бизнес-моделей из-за их вырождения. Однако, при формировании требований к корпоративным системам управления представление верхних уровней процессной модели организации в виде системы контуров саморегулирования является важнейшим критерием разграничения двух классов систем. Речь идет, собственно, о системе управления предприятиями, поставляющей ЛПР проекты управляющих решений, и «информирующей» системе, поставляющей ЛПР лишь вспомогательную информацию, которая в той или иной степени может быть использована для разработки проекта решения.

Кроме того, наличие в модели БП базовой операции (1) является критерием разграничения двух классов «информирующих» систем: систем с пассивным и активным информированием. Известно, что основными функциями «информирующих» систем являются функции учета (бухгалтерского, управленческого и т.п.) и диагностики состояния. Большинство известных в настоящее время корпоративных «информирующих» систем имеют недостаточно развитые функции диагностики. Они, как правило, ограничиваются функцией формирования пассивного (часто безадресного) сообщения о критической ситуации.

Например, в коммуникационной области количество таких ситуаций, связанных с учетом предоставляемых услуг в современных биллинговых системах, может быть очень велико. При этом, способы формирования диагностических сообщений разнообразны (текстовые сообщения, цветовая и звуковая сигнализация, почта и т.п.). Однако, неадекватная реакция на эти сообщения, их игнорирование, попытки «обмануть» систему диагностики ведут к существенным издержкам. Поэтому, без функции интеллектуальной диагностики действий персонала, являющихся реакцией на сообщения, эффективность диагностики в целом остается малоэффективной. Отсюда, важнейшим условием корректного исполнения персоналом рабочих заданий является обязательное включение в модель бизнес процессов не только операции (3), но и связанной с ней операции (1).

Представленная на Рис. 1. процессная модель организации является одним из возможных ограничений высшего уровня на существующие нотации моделирования и может быть рекомендована для использования в организациях в качестве снижающего многообразие предметно-ориентированного стандарта организационного проектирования первого уровня.

Таким образом, мы убедились, что существуют определенные методические ограничения на описание БП, определяемые методом управления, которые уменьшают многообразие. Очевидно, что эти ограничения являются довольно жесткими в сравнении с ситуацией отсутствия этих ограничений. К сожалению, ни один из существующих инструментов РБП не предоставляет сервис, поддерживающий декомпозицию всех БП на процессы анализа, моделирования и регулирования. В этом смысле все известные альтернативы инструментов неудачны потому, что, пытаясь описать каждый БП в виде контура самоуправления, модельер будет испытывать перегрузку, проделывая большой объем ручной работы. Нужен ли ему в этом случае «широкий, но мелкий инструмент»? Нужна ли ему в этой ситуации свобода творчества? Если он стремится к минимизации ошибок и снижению риска быть непонятым, то, естественно, ответ на поставленный вопрос будет отрицательным, а предпочтение будет опять отдано инструментам, поддерживающим SADT, по причинам уже указанным ранее.

Знание целей определяет критерии оценки инструментов РБП

Как известно, современные CASE средства используют не только в РБП, но и для узких задач. Например, для разработки средств программной поддержки исполнения БП. Как правило, эти функции поддерживаются в одном инструменте (ARIS, STORM2000) или системе согласованных друг с другом инструментов (ORACLE Designer, BPwin/Erwin/Paradigm Plus; Rational Suite).

Методически функции формирования требований к БП и разработки систем по требованиям реализуются по-разному. В первом случае осуществляется движение от «абстрактного» к «конкретному», а во втором – наоборот, от «конкретного» к «абстрактному». В части «конкретного» (техническое задание, требования и т.п.) эти движения пересекаются. Во втором случае «абстрактным» является множество связанных программных объектов, а в первом случае - множество БП уже формализованных на данный момент. В примитивном варианте – это, например, первый лист IDEF0 диаграммы.

Различные направления движений определяют и различные требования к проектному инструменту и психологии проектировщика. В первом случае творчество не приветствуется, а требуется четкость, конкретика, следование корпоративным и международным стандартам, а также процедурам групповой экспертизы и т.п., а во втором - широкий спектр возможностей для творческой реализации заданных спецификаций.

В случае разработки требований к БП реализация процедур коллективной экспертизы проектных документов приобретает первостепенное значение. Поэтому в обсуждениях альтернативных инструментов организационного проектирования использование такого аргумента как «наличие средств поддержки групповой экспертизы проектных документов» является крайне необходимым. Но, не многие инструменты РБП, поддерживают такую функцию.

К сожалению, задачу разработки требований с помощью CASE-средств из-за недостаточной квалификации заказчика решают, как правило, именно те, кто призван разрабатывать средства программной поддержки. Очевидно, чем менее четко сформулированы требования к средствам программной поддержки, тем сильнее будет многообразие и больше возможностей для нарушения системности проекта, называемого разработчиком «творчеством». Поэтому трудно воздержаться, чтобы встречающуюся неудовлетворенность модельера стандартом IDEF0 не объяснять лишь неконтролируемым психическим фактором - неадекватным стремлением к свободе творчества.

Выводы

Мы видим, что задача управления изменениями в организации осложняется «проектным хаосом», обусловленным многообразием возможностей и их сочетаний, вносимых языком (нотациями) описания БП, возможностями инструмента, концепциями управления и представлениями о БП. Условия усиления «проектного хаоса» объективно создаются разработчиками и поставщиками инструментов. Мы не видим на рынке предложения инструментов, одновременно ориентированных на поддержку РБП и эффективно подавляющих многообразие. Именно поэтому справедлива постановка вопроса, вынесенного в заголовок статьи. Итак, какой же из известных инструментов РБП принесет организации наименьший вред?

Ответ очевиден – это инструменты «узкие, но глубокие» лишающие разработчика той части «творческих» возможностей, которые ведут к многообразию эквивалентных с точки зрения целей РБП представлений систем. Это потому, что такое многообразие на этапе разработки моделей БП ведет не к расширению вариантов альтернативных решений, а к - «проектному хаосу». Я последовательно пытался показать, что в наибольшей степени свойствами подавления ментальных шумов и целенаправленности обладает методология SADT. Однако, и она не идеальна. Проектирование в BPwin модели, изображенной на Рис.1, видится очень трудоемкой, а сама модель представляется в виде «дурной» бесконечности триад «анализ – моделирование - регулирование (поставка)». Следовательно, степень конгруэнтности SADT «кибернетическому стандарту» или концепции контроллинга крайне низка.

Проблема современного инструментария РБП обусловлена не только отсутствием «узкого и жесткого» инструмента, ориентированного на поддержку РБП, о чем говорилось выше, но и общей культурой потребителя, формирующего рынок. Порою складывается впечатление, что существующие CASE средства удовлетворяют в первую очередь потребностям двух групп потребителей. К первой группе относятся пользователи, озабоченные разработкой функциональной модели организации, являющейся «слепком» с административной структуры. Очевидно, что в эпоху торжества процессной парадигмы это явление является атавизмом, существование которого можно оправдать лишь наличием задачи наукообразного обоснования штатных клеток и неадекватного распределения фонда заработной платы. Ко второй группе мы отнесем уважаемых разработчиков средств программной поддержки, которые вполне бы удовлетворились инструментом класса ORACLE Designer (совершенный, но не мобильный) или даже MS Visial Studio (эффективный, но без репрезентативных свойств), если бы не «досадная» обязанность общаться с заказчиком. Поэтому представленные в настоящей статье требования к инструментарию РБП ориентированы на довольно узкий, возможно, только зарождающийся сегмент рынка.

Любой субъективный анализ CASE-инструментов должен вызывать здоровое сомнение. Последнее в полной мере относится и к настоящей статье. Доверие к ней должно подкрепляться мнением авторитетных экспертов. Естественно, автор не считает, что именно эта статья должна послужить основной темой для размышлений специалистов. Проблема видится шире. Мы не можем ожидать в ближайшее время создания в нашей стране организации, подобной ISA, которая взвалила на себя решение в национальном масштабе задачи стандартизации бизнес-процессов [7]. Количество мнений по затронутой теме давно превысило количество людей, формирующих эти мнения, софтверные компании не могут по объективным причинам в одиночку решить задачу по созданию инструментария РБП, а российский бизнес-консалтинг никак не выберется из «детской песочницы». Путь взросления – это приобретение навыков кооперации в рамках сложных проектов, подобных разработке инструментария РБП. Время сотрудничества в рамках цивилизованной ассоциативной работы над российскими стандартами РБП назрело.

1.     Панащук С. Проектирование крупных ИС: от панацей к мастерской методов и моделей // Директору информационной службы, 1998, 2

2.     Зиндер Е.З. О мастерской и мастерстве. // Директору информационной службы, 1998, 2

3.     Бир С. Мозг фирмы. - Москва: Радио и связь, 1993.- 416.

4.     Рубцов С.В. Уточнение понятия бизнес-процесс. В монографии «Целевое управление корпорациями». 2001. URL: http://or-rsv.narod.ru/Book/Book_3.htm#Refining_of_BP

5.     Chase R. B. , Aquilano N. J. , Jacobs R. F. Production and operations management : manufacturing and services. - Boston: Irwin, 1998.- 889.

6.     Aquilano N. J. , Chase R. B. , Davis M. M. Fundamentals of operations management. - Chicago: Irwin, 1995.- 667.

7.     Рубцов С.В. Исследование операций - методология научного менеджмента. Что такое современный научный менеджмент? // БОСС - Бизнес: организация, стратегии, системы, 2000, 11, 48-51

8.     Williams T. J. Enterprise Integration in the Process Industries - as Seen by the ISA SP95 committee. - West Lafayette, Purdue University: World Batch Forum, 1998.- 46.

[1] Гомеостаз – способность системы поддерживать ее критические параметры в допустимых преде лах в условиях случайных помех и возмущений